home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
TeX 1995 July
/
TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO
/
tex-k
/
tex-k-archive.past
/
tex-k-archive.gz
/
tex-k-archive
/
000651_kb@cs.umb.edu_Wed Jun 15 02:25:15 1994.msg
< prev
next >
Wrap
Internet Message Format
|
1994-10-11
|
2KB
Received: from ra.cs.umb.edu by cs.umb.edu with SMTP id AA21675
(5.65c/IDA-1.4.4 for <tex-k-exp@cs.umb.edu>); Wed, 15 Jun 1994 06:25:16 -0400
Received: by ra.cs.umb.edu id AA13569
(5.65c/IDA-1.4.4 for tex-k); Wed, 15 Jun 1994 06:25:15 -0400
Date: Wed, 15 Jun 1994 06:25:15 -0400
From: "K. Berry" <kb@cs.umb.edu>
Message-Id: <199406151025.AA13569@ra.cs.umb.edu>
To: tex-k@cs.umb.edu
Subject: latex2e vs. latex209 inputs
With the advent of latex2e, I suspect most people trying to install it
will notice a deficiency in the current released version of kpathsea --
if you use the ls-R database feature to speed up searches (as
recommended), then the programs always find whatever is first in the
database, even if your input path looks like
TEXINPUTS = .:$TEXMFROOT/tex/latex209//:$TEXMFROOT/tex//
vs.
TEXINPUTS = .:$TEXMFROOT/tex/latex2e//:$TEXMFROOT/tex//
(i.e., it doesn't necessarily find the file in order of the specified path.)
The cure for this is to implement the `match' function in db.c, as a
patch posted a couple days ago did (among many other useful things). I
will be incorporating that `match' (or its equivalent) into the next
version, so you may as well try it now.
I also want to solicit people's opinions on (more or less) how long they
think latex209 is going to stick around. Right now, the only way (so far
as I know) to get the different path definitions above for the different
versions of latex is to use a script, which is annoying. An alternative
would be to allow syntax something like:
TEXINPUTS.latex209 = <foo>
TEXINPUTS.latex = <bar>
where the `.<program>' suffix means the path definition applies only for
that executable name.
However, latex is the only thing that needs this, and I can't think of
any other application for this feature (given ls-R), and hence I am not
anxious to implement it if it's not going to be needed in (say) six months.
(I don't know when the next release will be ready. No sooner than a few
weeks, anyway.)